Re: --skip-worktree and operations like checkout / stash /etc.
In the meantime I've created this simple script, but what a hack...
#!/bin/bash
git ls-files -v | grep "^S " | cut -c3- | readarray ignored
for x in "${ignored[@]}"; do
git update-index --no-skip-worktree -- "$x"
done
git checkout -m $@
for x in "${ignored[@]}"; do
git update-index --skip-worktree -- "$x"
done
Regards,
Raman
On Thu, Sep 27, 2018 at 6:29 PM Raman Gupta wrote:
>
> The comand `update-index --skip-worktree` seems to be an ideal way to
> tell git to locally ignore some modified files. However, this seems
> not to play well with very common commands like `checkout` and
> `stash`.
>
> $ git checkout other-branch
> error: Your local changes to the following files would be overwritten
> by checkout:
> path/to/ignored/file
> Please commit your changes or stash them before you switch branches.
> Aborting
>
> Ok, well lets try stashing:
>
> $ git stash save
> No local changes to save
>
> Ok, lets try a checkout with a merge:
>
> $ git checkout -m other-branch
> error: Entry 'path/to/ignored/file' not uptodate. Cannot merge.
>
> Ok, lets force this sucker:
>
> $ git checkout -f other-branch
> error: Entry 'path/to/ignored/file' not uptodate. Cannot merge.
>
> Ok, at this point I'm wondering, do I really need to
> --no-skip-worktree all the ignored files, do my `checkout -m`, and
> then ignore them again? Umm, no, that ain't gonna work.
>
> I'd love for git to just check if my worktree-skipped changes will
> merge cleanly into the target branch, and if they do so, go ahead and
> do that merge (with perhaps a notification printed to the console) and
> keep the skip worktree status. If the merge ends up with a conflict,
> then feel free to no-worktree-skip it and show me merge conflicts.
>
> Regards,
> Raman
--skip-worktree and operations like checkout / stash /etc.
The comand `update-index --skip-worktree` seems to be an ideal way to tell git to locally ignore some modified files. However, this seems not to play well with very common commands like `checkout` and `stash`. $ git checkout other-branch error: Your local changes to the following files would be overwritten by checkout: path/to/ignored/file Please commit your changes or stash them before you switch branches. Aborting Ok, well lets try stashing: $ git stash save No local changes to save Ok, lets try a checkout with a merge: $ git checkout -m other-branch error: Entry 'path/to/ignored/file' not uptodate. Cannot merge. Ok, lets force this sucker: $ git checkout -f other-branch error: Entry 'path/to/ignored/file' not uptodate. Cannot merge. Ok, at this point I'm wondering, do I really need to --no-skip-worktree all the ignored files, do my `checkout -m`, and then ignore them again? Umm, no, that ain't gonna work. I'd love for git to just check if my worktree-skipped changes will merge cleanly into the target branch, and if they do so, go ahead and do that merge (with perhaps a notification printed to the console) and keep the skip worktree status. If the merge ends up with a conflict, then feel free to no-worktree-skip it and show me merge conflicts. Regards, Raman
Created an open source repo for gitworkflow
As one step towards raising awareness in the developer community and making "gitworkflow" [1] more accessible, I am creating a home for gitworkflow on GitHub: https://github.com/rocketraman/gitworkflow My intention with this repository is to have a central place in which to write and collect readable documentation for gitworkflow, such as concept summaries, useful commands, and task-oriented primers, keep a curated "Awesome List" of links to related articles and docs, and a place for developers to ask questions and collaborate on related tooling and techniques. This is a work in progress, but let’s see where it goes! I'd love to see some participation from people on this list. [1] https://git-scm.com/docs/gitworkflows#_managing_branches
Re: [PATCH v2] contrib/rerere-train: optionally overwrite existing resolutions
On 26/07/17 04:41 PM, Junio C Hamano wrote: > Raman Gupta <rocketra...@gmail.com> writes: > >> On 26/07/17 02:05 PM, Junio C Hamano wrote: >>> I haven't tried this patch, but would this work well with options >>> meant for the 'git rev-list --parents "$@"' that grabs the list of >>> merge commits to learn from? e.g. >>> >>> $ contrib/rerere-train.sh -n 4 --merges master >>> $ contrib/rerere-train.sh --overwrite -n 4 --merges master >>> $ contrib/rerere-train.sh -n 4 --overwrite --merges master >>> >>> I do not think it is necessary to make the last one work; as long as >>> the first two work as expected, we are good even if the last one >>> dies with a sensible message e.g. "options X, Y and Z must be given >>> before other options" (currently "X, Y and Z" consists only of >>> "--overwrite", but I think you get what I mean). >> >> You're right -- I didn't try all the cases. I wasn't able to figure >> out how to get `rev-parse --parseopt` to deal with this situation, so >> I did it manually. I'm not super-happy with the result, but it does >> work. Look for PATCH v3. > > Yes, I think you could squash the two case arms in the later loop > into one i.e. > > -h|--help|-o|--overwrite) > die "please don't." ;; I considered that but decided the non-collapsed version better supports this list growing in the future. > but still the repetition does look ugly. Agreed. > As a contrib/ material, I do not care too deeply about it, though. > > Will queue. Thanks. Regards, Raman
[PATCH v3] contrib/rerere-train: optionally overwrite existing resolutions
Provide the user an option to overwrite existing resolutions using an `--overwrite` flag. This might be used, for example, if the user knows that they already have an entry in their rerere cache for a conflict, but wish to drop it and retrain based on the merge commit(s) passed to the rerere-train script. Signed-off-by: Raman Gupta <rocketra...@gmail.com> --- contrib/rerere-train.sh | 54 +++-- 1 file changed, 52 insertions(+), 2 deletions(-) diff --git a/contrib/rerere-train.sh b/contrib/rerere-train.sh index 52ad9e4..45d 100755 --- a/contrib/rerere-train.sh +++ b/contrib/rerere-train.sh @@ -3,10 +3,56 @@ # Prime rerere database from existing merge commits me=rerere-train -USAGE="$me rev-list-args" +USAGE=$(cat <<-EOF +usage: $me [--overwrite] + +-h, --helpshow the help +-o, --overwrite overwrite any existing rerere cache +EOF +) SUBDIRECTORY_OK=Yes -OPTIONS_SPEC= + +overwrite=0 + +while test $# -gt 0 +do + opt="$1" + case "$opt" in + -h|--help) + echo "$USAGE" + exit 0 + ;; + -o|--overwrite) + overwrite=1 + shift + break + ;; + --) + shift + break + ;; + *) + break + ;; + esac +done + +# Overwrite or help options are not valid except as first arg +for opt in "$@" +do + case "$opt" in + -h|--help) + echo "$USAGE" + exit 0 + ;; + -o|--overwrite) + echo "$USAGE" + exit 0 + ;; + esac +done + . "$(git --exec-path)/git-sh-setup" require_work_tree cd_to_toplevel @@ -34,6 +80,10 @@ do # Cleanly merges continue fi + if test $overwrite = 1 + then + git rerere forget . + fi if test -s "$GIT_DIR/MERGE_RR" then git show -s --pretty=format:"Learning from %h %s" "$commit" -- 2.9.4
Re: [PATCH v2] contrib/rerere-train: optionally overwrite existing resolutions
On 26/07/17 02:05 PM, Junio C Hamano wrote: > I haven't tried this patch, but would this work well with options > meant for the 'git rev-list --parents "$@"' that grabs the list of > merge commits to learn from? e.g. > > $ contrib/rerere-train.sh -n 4 --merges master > $ contrib/rerere-train.sh --overwrite -n 4 --merges master > $ contrib/rerere-train.sh -n 4 --overwrite --merges master > > I do not think it is necessary to make the last one work; as long as > the first two work as expected, we are good even if the last one > dies with a sensible message e.g. "options X, Y and Z must be given > before other options" (currently "X, Y and Z" consists only of > "--overwrite", but I think you get what I mean). You're right -- I didn't try all the cases. I wasn't able to figure out how to get `rev-parse --parseopt` to deal with this situation, so I did it manually. I'm not super-happy with the result, but it does work. Look for PATCH v3. Regards, Raman
[PATCH v2] contrib/rerere-train: optionally overwrite existing resolutions
Provide the user an option to overwrite existing resolutions using an `--overwrite` flag. This might be used, for example, if the user knows that they already have an entry in their rerere cache for a conflict, but wish to drop it and retrain based on the merge commit(s) passed to the rerere-train script. Signed-off-by: Raman Gupta <rocketra...@gmail.com> --- contrib/rerere-train.sh | 36 ++-- 1 file changed, 34 insertions(+), 2 deletions(-) diff --git a/contrib/rerere-train.sh b/contrib/rerere-train.sh index 52ad9e4..e25bf8a 100755 --- a/contrib/rerere-train.sh +++ b/contrib/rerere-train.sh @@ -3,10 +3,38 @@ # Prime rerere database from existing merge commits me=rerere-train -USAGE="$me rev-list-args" SUBDIRECTORY_OK=Yes -OPTIONS_SPEC= +OPTS_SPEC="\ +$me [--overwrite] +-- +h,helpshow the help +o,overwrite overwrite any existing rerere cache +" +eval "$(echo "$OPTS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?)" + +overwrite=0 + +while test $# -gt 0 +do + opt="$1" + case "$opt" in + -o) + overwrite=1 + shift + shift + ;; + --) + shift + break + ;; + *) + break + exit 1 + ;; + esac +done + . "$(git --exec-path)/git-sh-setup" require_work_tree cd_to_toplevel @@ -34,6 +62,10 @@ do # Cleanly merges continue fi + if [ $overwrite == 1 ] + then + git rerere forget . + fi if test -s "$GIT_DIR/MERGE_RR" then git show -s --pretty=format:"Learning from %h %s" "$commit" -- 2.9.4
Re: [RFC] Git rerere and non-conflicting changes during conflict resolution
On 25/07/17 01:52 PM, Jeff King wrote: > On Tue, Jul 25, 2017 at 11:09:55AM -0400, Raman Gupta wrote: > >> I had an interesting situation today: resolving a merge conflict >> required modification in other files that were not themselves conflicting. >> >> I just realized that rerere does not remember any changes to these >> additional files -- only changes to the conflicting files. This makes >> the end result of rerere obviously incorrect in this situation. >> >> So my questions are: >> >> 1) Is this a known limitation or is there a reason rerere works in >> this manner? > > Yes, it's known. Rerere works by storing a mapping of conflicted hunks > to their resolutions. If there's no conflicted hunk, I'm not sure how > we'd decide what to feed into the mapping to see if there is some > content to be replaced. > > That said, I'm far from an expert on how rerere works. Junio might have > ideas on how we could handle this better. But I do note that for > repeated integration runs (like we do for topics in git.git, as they get > merged to "pu", then "next", then "master"), he keeps non-conflict > fixups in a separate commit which gets squashed into the merge > automatically. See > > https://github.com/git/git/blob/todo/Reintegrate#L185-L191 Seems relatively simple to me, at least conceptually. 1) Store the state of the index after the merge. 2) After conflict resolution is complete (i.e. user executes "git commit"), diff index @ step 1 with commit. 3) Assume that all changes in that diff are related to conflict resolution (as they should be), and save that diff to the rerere cache. I could be missing something fundamental here though... >> 1b) If it is a limitation/bug, what would be needed to fix it? With >> some guidance, I might be able to submit a patch... > > As far as I know, something like the Reintegrate script above is the > state of the art. IMHO it would be useful if something similar were > integrated into rerere, but I'm not sure exactly how it would know when > to trigger. I've seen the Reintegrate script before. It is very specific to the git.git workflow. I think it makes sense to expose this particular capability in git proper, given that rerere itself is exposed. Plus that could actually simplify the Reintegrate script a bit. >> 2) In the meantime, is there a way I can identify these cases, without >> which I cannot really trust rerere is doing the right thing? > > I do think it would be useful if rerere could look at a merge result and > say "OK, I've recorded these bits, but there are other lines that are > not part of either parent and which are not part of a conflict". That > gives you a warning that such lines need to be part of a fixup (rather > than you being surprised when you redo the merge later and have to > rework the fixup). Agreed. > But I don't think even then you can ever trust rerere fully. > Fundamentally you're applying some changes from one merge into another > context. There may be new sites that also need fixing up, and the tool > has no way to know. So you should treat a rerere-helped merge as any > other merge: assume it's a good starting point but use other tools (like > the compiler or automated tests) to confirm that the result is sensible. While I agree that every case cannot be handled, and this type of validation is still necessary, I believe git should cover the cases which it is proper and possible to cover. > -Peff > Regards, Raman
[RFC] Git rerere and non-conflicting changes during conflict resolution
I had an interesting situation today: resolving a merge conflict required modification in other files that were not themselves conflicting. I just realized that rerere does not remember any changes to these additional files -- only changes to the conflicting files. This makes the end result of rerere obviously incorrect in this situation. So my questions are: 1) Is this a known limitation or is there a reason rerere works in this manner? 1b) If it is a limitation/bug, what would be needed to fix it? With some guidance, I might be able to submit a patch... 2) In the meantime, is there a way I can identify these cases, without which I cannot really trust rerere is doing the right thing? Regards, Raman
[PATCH/RFC] contrib: rerere-train overwrites existing resolutions
>From 41116889f7eb2ddd590d165d9ca89646f7b15aaf Mon Sep 17 00:00:00 2001 From: Raman Gupta <rocketra...@gmail.com> Date: Tue, 25 Jul 2017 10:28:35 -0400 Subject: [PATCH] contrib: rerere-train overwrites existing resolutions When running rerere-train, the user is explicitly asking the training to occur based on the current merge commit. However, if the current cache has a resolution for the same conflict (even if out of date or wrong), rerere-train does not currently update the rr-cache. Now, forget existing resolutions before training so that training is always reflective of the trained data. --- contrib/rerere-train.sh | 1 + 1 file changed, 1 insertion(+) diff --git a/contrib/rerere-train.sh b/contrib/rerere-train.sh index 52ad9e4..a222d38 100755 --- a/contrib/rerere-train.sh +++ b/contrib/rerere-train.sh @@ -34,6 +34,7 @@ do # Cleanly merges continue fi + git rerere forget . if test -s "$GIT_DIR/MERGE_RR" then git show -s --pretty=format:"Learning from %h %s" "$commit" -- 2.9.4
Re: Article on the branch strategy in gitworkflows(7)
FYI - the article mentioned below has been published @ https://medium.com/@ramangupta/how-the-creators-of-git-do-branches-e6fcc57270fb Thank you to the two or three people that I know of that took the time to read the draft. Regards, Raman On 22/03/17 12:41 PM, Raman Gupta wrote: > Several years ago, I contributed [1] to the gitworkflows(7) > documentation, because I thought the process by which git.git does > branching was really interesting. > > Since then, I have found it odd that gitworkflows has mostly remained > under the radar. Other, in my opinion, lesser flows, have become very > popular, like GitFlow [2]. I have written an article explaining the > "why" of gitworkflow in contrast to GitFlow and others: > > https://docs.google.com/document/d/1cGNujRNVzeLV2SXkVlKwai6qJmlVT3LwlOsVYNr0FZo/edit?usp=sharing > > This article is not published yet -- its still a DRAFT and only > visible via the above URL. > > I'd love to have input on the draft from the experts in this > community. Feel free to suggest changes and add comments in the > article via Google Docs. > > Also, some explanatory illustrations to accompany the article would be > excellent, if anyone feels like contributing. Visuals are not my > strong suit. I'd love to include something similar to the graphic [3] > that was a big part of making GitFlow so popular. The article can be > partially rewritten to match illustrations, if any are contributed. > > [1] > https://github.com/git/git/commit/382e54312220ac02586a3cbb06b0e4eb7789f043 > > [2] http://nvie.com/posts/a-successful-git-branching-model/ > > [3] http://nvie.com/img/git-mo...@2x.png > > Regards, > Raman Gupta >
Article on the branch strategy in gitworkflows(7)
Several years ago, I contributed [1] to the gitworkflows(7) documentation, because I thought the process by which git.git does branching was really interesting. Since then, I have found it odd that gitworkflows has mostly remained under the radar. Other, in my opinion, lesser flows, have become very popular, like GitFlow [2]. I have written an article explaining the "why" of gitworkflow in contrast to GitFlow and others: https://docs.google.com/document/d/1cGNujRNVzeLV2SXkVlKwai6qJmlVT3LwlOsVYNr0FZo/edit?usp=sharing This article is not published yet -- its still a DRAFT and only visible via the above URL. I'd love to have input on the draft from the experts in this community. Feel free to suggest changes and add comments in the article via Google Docs. Also, some explanatory illustrations to accompany the article would be excellent, if anyone feels like contributing. Visuals are not my strong suit. I'd love to include something similar to the graphic [3] that was a big part of making GitFlow so popular. The article can be partially rewritten to match illustrations, if any are contributed. [1] https://github.com/git/git/commit/382e54312220ac02586a3cbb06b0e4eb7789f043 [2] http://nvie.com/posts/a-successful-git-branching-model/ [3] http://nvie.com/img/git-mo...@2x.png Regards, Raman Gupta
