Johannes Schindelin <[EMAIL PROTECTED]> writes:
> Instead, how about writing a stash pop? "git stash pop []". It
> would literally just call git stash apply && git reflog delete. Should
> not be too difficult, now that I provided "git reflog delete" ;-)
>
> Maybe even deprecating "git stash cl
Hi,
On Tue, 2 Oct 2007, Eric Blake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> [adding the git list]
>
> According to Bruno Haible on 10/2/2007 5:50 AM:
> > Hello Benoit,
> >
> >>> $ git stash
> >>> $ git pull
> >>> $ git stash apply
> >>> $ git stash clean
On Oct 9, 2007, at 2:03 PM, Bruno Haible wrote:
Hello Benoit,
Thanks for working on this. But this merge driver has a few major
nits.
1) While my ChangeLog file was locally unmodified but some pulled
in commits
should modify it, "git pull" stopped and said:
ChangeLog: needs update
f
Hello Benoit,
Thanks for working on this. But this merge driver has a few major nits.
1) While my ChangeLog file was locally unmodified but some pulled in commits
should modify it, "git pull" stopped and said:
ChangeLog: needs update
fatal: Entry 'ChangeLog' not uptodate. Cannot merge.
[I c
Hi,
On Mon, 8 Oct 2007, Benoit SIGOURE wrote:
> [as usual, I forgot the attachment...]
Two comments:
- by not inlining you made it hard to review your script. Therefore I
will not do it.
- Try to avoid naming the script git-merge-*; these scripts/programs are
merge _strategies_, not mer
[as usual, I forgot the attachment...]
On Sep 30, 2007, at 10:27 PM, Benoit SIGOURE wrote:
On Sep 30, 2007, at 9:41 PM, Bruno Haible wrote:
it should be
possible to create a custom [merge "cl-merge"] in your git config
file,
which points to a script designed specifically for resolving
cha
On Sep 30, 2007, at 10:27 PM, Benoit SIGOURE wrote:
On Sep 30, 2007, at 9:41 PM, Bruno Haible wrote:
it should be
possible to create a custom [merge "cl-merge"] in your git config
file,
which points to a script designed specifically for resolving
changelog
conflicts
I would love such a
Benoit SIGOURE wrote:
> >>> Is there some shorthand for this process, such as a "git-recover"
> >>> command?
> >>
> >> you can run git fsck and look for
> >> a dangling commit (which can be inspected with git show ) where
> >> you are most likely to find your stash (unless you run git-gc or this
>
Hi,
I wrote:
> "git lost-found" does not work well for me: I stopped it after it ate
> 10 minutes of CPU time without producing a result.
It's not a bug, it's just slow:
$ git-fsck
dangling commit f62c4fa05422fd4fb8610bdb02a7160121657893
(took 4 sec)
$ git-lost-found
[f62c4fa05422fd4fb8610bdb02
On Oct 2, 2007, at 1:50 PM, Bruno Haible wrote:
Hello Benoit,
$ git stash
$ git pull
$ git stash apply
$ git stash clean ; typo!
$ git stash clear ; fatal correction to typo!
and lost 20 modified files. Well, not really lost. Just took me a
while
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[adding the git list]
According to Bruno Haible on 10/2/2007 5:50 AM:
> Hello Benoit,
>
>>> $ git stash
>>> $ git pull
>>> $ git stash apply
>>> $ git stash clean ; typo!
>>> $ git stash clear ; fatal cor
Hello Benoit,
> > $ git stash
> > $ git pull
> > $ git stash apply
> > $ git stash clean ; typo!
> > $ git stash clear ; fatal correction to typo!
> >
> > and lost 20 modified files. Well, not really lost. Just took me a
> > while to
>
> I don't rea
[I forgot to reply all, sorry Bruno -- I also edited the end of the
message]
On Oct 2, 2007, at 3:47 AM, Bruno Haible wrote:
Hi,
$ git stash
$ git fetch
$ git rebase origin/master
$ git stash apply
$ git stash clear
$ git reset
Note that "git stash clear" is a dangerous com
Hi,
> $ git stash
> $ git fetch
> $ git rebase origin/master
> $ git stash apply
>
> $ git stash clear
> $ git reset
Note that "git stash clear" is a dangerous command. I recommend to use it
only after "git stash list" and/or "git status".
I just did this:
$ git stash
$ g
On Sep 30, 2007, at 9:41 PM, Bruno Haible wrote:
it should be
possible to create a custom [merge "cl-merge"] in your git config
file,
which points to a script designed specifically for resolving
changelog
conflicts
I would love such a script, instead of constantly having to do
conflict
> it should be
> possible to create a custom [merge "cl-merge"] in your git config file,
> which points to a script designed specifically for resolving changelog
> conflicts
I would love such a script, instead of constantly having to do conflict
resolution at the top of ChangeLog.
Bruno
Hello Benoit,
> You shouldn't pull if you want to rebase. Read man git-pull, it
> clearly states that pull = fetch + merge in current branch. If you
> want to rebase, you don't want to merge. That's why you had to solve
> conflicts twice (once for merge, once for rebase). The resulting
On Sep 30, 2007, at 4:48 PM, Bruno Haible wrote:
Hello Jim,
- Did "git pull". It told me:
Then (everything is committed), you switch to the trunk and pull
(update from public repo) from there:
git checkout master
git pull
then go back to your branch and use git-rebase to make your br
Bruno Haible <[EMAIL PROTECTED]> wrote:
...
> Right?
That sounds reasonable.
I usually switch to master, pull, then switch back and then rebase.
Probably not much difference.
Another command you might like: git-stash.
It's relatively new, so install a newer version
of git if you don't have it yet
Hello Jim,
> > - Did "git pull". It told me:
>
> Then (everything is committed), you switch to the trunk and pull
> (update from public repo) from there:
>
> git checkout master
> git pull
>
> then go back to your branch and use git-rebase to make your branch
> change set(s) apply cleanly
Jim Meyering wrote:
> I've learned not to modify ChangeLog on my private branches.
Certainly the ChangeLog will be the file that causes the most conflicts.
But conflicts can occur any time, even for intended short-lived modifications,
therefore I need to learn how to deal with conflicts even if th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 9/30/2007 6:21 AM:
> But I had to resolve the conflicts twice, which is inefficient. Any hint
> how to avoid that?
git rerere is supposed to be able to help with repeated rebase resolution
(git remembers how you resolved a
Bruno Haible <[EMAIL PROTECTED]> wrote:
> A git question:
>
> In http://lists.gnu.org/archive/html/bug-gnulib/2007-09/msg00130.html
> you wrote:
>> When one branch (your topic branch) is private, you *can* rebase, and thus
>> avoid the merge.
>> ...
>> That's the whole point of rebasing.
>> rebasin
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Hi Jim,
>
> A git question:
>
> In http://lists.gnu.org/archive/html/bug-gnulib/2007-09/msg00130.html
> you wrote:
>> When one branch (your topic branch) is private, you *can* rebase, and thus
>> avoid the merge.
>> ...
>> That's the whole point of rebasing
Hi Jim,
A git question:
In http://lists.gnu.org/archive/html/bug-gnulib/2007-09/msg00130.html
you wrote:
> When one branch (your topic branch) is private, you *can* rebase, and thus
> avoid the merge.
> ...
> That's the whole point of rebasing.
> rebasing is essentially adjusting your deltas so t
25 matches
Mail list logo
